1. Field of the Invention
The present invention relates generally to a mobile broadcast system supporting Mobile Broadcast Service (BCAST), and in particular, to a method and apparatus for sending a notice of a notification event, like system and service changes, to one or a group of terminals.
2. Description of the Related Art
Owing to today's development of communication and broadcasting technologies, broadcasting systems or mobile communication systems provide BCAST services. A BCAST service that additionally sends packet data on a broadcast channel beyond the traditional audio- and video-oriented broadcast service is now under discussion.
BCAST is the process of service discovery and subscription by a BCAST-enabled terminal, provisioning of control information associated with the BCAST service, and transmission and reception of the BCAST service. Changes may occur due to many factors during the BCAST service and some of the changes must necessarily be notified to the terminal. Such changes are about service schedule or service reception information, for example.
A Service Guide (SG) providing information about BCAST services is essential to the terminal's service discovery. For BCAST reception, terminals always receive the SG.
FIGS. 1A and 1B illustrate an SG used in a conventional mobile broadcast system. Typical traditional audio/video broadcast services and packet transmission service are provided as BCAST services in the illustrated case. Specifically, FIG. 1A illustrates the structure of an SG message or file containing SG information about a plurality of BCAST services. FIG. 1B illustrates the structure of each SG in the SG message or file.
Referring to FIG. 1A, a Header 101 indicates the number of SGs in the SG message or file and the Identifier (ID), version, and length of the SG message or file. The terminal acquires generic information about the SG message from the Header 101. Reference numerals 102 and 103 denote SGs for BCAST service #1 to BCAST service #n. The structure of these SGs is illustrated in detail in FIG. 1B.
Referring to FIG. 1B, for each SG, a Header 111 includes general information about the SG, such as information about individual blocks in the SG, a service ID, and the version and length of the SG. Access Info 112 indicates how the BCAST service corresponding to the SG can be received. Thus, the Access Info 112 provides information about a channel on which the BCAST service is provided, the schedule of the BCAST service, and other information associated with reception of the BCAST service. Provisioning Info 113 provides billing information or security information required to receive the BCAST service. Terminal Requirement 114 indicates requirements for the terminal to receive the BCAST service. Besides these information blocks 112, 113 and 114, Preview Info 115 can further be included to provide preview information about the BCAST service.
Some of the SGs may vary at any time and each time an SG is changed, the updated SG must be sent. Considering, as is often the case in the nature of mobile broadcast, new terminals may join the BCAST service, the SG must be transmitted repeatedly even though the SG is not changed. For instance, if a user wants to join the BCAST service by turning on his terminal, or if a terminal needs to receive the SG as it roams, such a terminal must receive the SG separately from existing terminals already receiving the BCAST service.
Therefore, even the terminals which have already received the SG will also receive the SG and must check whether the SG has been updated. Since the SG is a message from an Application level, the highest level in a communications or broadcast protocol stack, the terminal cannot verify the current SG until receiving the entire SG message. A shortcoming with this SG reception method is serious power consumption in the terminals. If two or three SG messages are delivered for one minute, the terminals continue operating their receivers to receive the SG messages even though they are not receiving the BCAST service.